[レポート]Riot Gamesは分析対象である大量のデータをどうやって捌けるようにしてきたか #reinvent

こんにちは。ゲームソリューション部の出村です。

AWS re:Invent 2022 にてBreakoutSessionである「How Riot Games processes 20TB of analytics data daily on AWS」に参加してきました。そのセッションレポートについてお届けします。

セッション概要

Riot Games ingests about 20 TB of data every day on AWS. This data powers a wide range of services including game matchmaking, in-game personalization, analytics, security, and player behavior management. Until recently, this data was only queryable for up to 6 hours after it was produced. With Amazon MSK, the team reduced time down to 5 minutes. Amazon MSK also allowed Riot Games to lower TCO and deprecate an aging map-reduce-based pipeline. In this session, Riot Games describes the before state, migration path, current state and future state of their data ingestion pipeline.

スピーカー

• Wesley Kerr, Head of Tech Research, Riot Games
• Karthik Kumar Odapally, Principal Solutions Architect for Riot Games, AWS

アジェンダ

このセッションでは、Riot Games（League of Legendsといったゲームを開発、運営している会社）が、過去から現在に渡って、毎日記録される大量のデータを分析するために、League of Legendsがリリースされた当初がどのようなアーキテクチャでであり、それに対する問題、その後のVALORANTとったゲームタイトルでは、どのように変更されていったという遍歴が解説されています。

セッション

本エントリーでは、初期のLeague of Legendsでのデータ収集時の問題とその解決策などについて解説しています。詳細については、本セッションの動画をご覧下さい。

RIOT Gamesについて

まずはライアットゲームズについての解説です RIOT Gamesの代表作としてはLeague of Legendsがあり2009年から運営されています。

このゲームは、現在、月に延べ1億人がプレイしています。他にもいくつかのゲームを開発、運営しているゲーム会社です。

League of Legendsでのデータ収集

そのような多くのユーザーがプレイしている League of Legends のデータ収集がリリース直後から現在までどのように変化してきたのかについてを取り上げて解説します。

アーキテクチャ初期 - Honu

リリース直後の段階ではオンプレミスのデータセンターでデータ収集した後、S3にデータを転送されていました。

S3にあるデータはEMRを使って処理され、Databrikcsなどで加工し、tableauなどの可視化ツールを使いデータサイエンティストたちが分析などを行っていました。

課題解決に対するチャレンジ

いくつかの課題解決に向けてチャレンジをしました。抱えていた課題は次のものがあります。

• Schemaless
• Lossy
• Many small files

Schemaless

スキーマレスについてです。プレイヤー間で発生したイベント（例えば、相手を倒したなど）を、キーと値を一体化したデータをクライアントからサーバへテキスト形式で送ります。それらのデータには、不具合に関するものも合わせて送信していました。

ただ、このようなデータ構造にすると、送信するデータによっては空白の項目が存在してしまうこともよくありました。また、データ項目によっては複数データを送信する必要もあり、その場合はJSON形式にしてデータを格納していました。

Lossy

データの消失についてです。データセンターを使ってデータをデータを収集していたため、例えばクリスマスシーズンなどの多くのユーザーがプレイする時期にはサーバへのアクセスでスパイクが発生し、データを書き込むディスク容量が一杯になることがありました。

Many small files

次に大量にあるファイルサイズの小さなファイル群についてです。これらのデータを取得して、分析しやすいよう加工し、より大きなファイルに変換してS3に書き込んでいます。これらのファイルの読み書きに時間がかかっていました。

Analytics Platform (AP)

これらの問題を解決するための新しい分析プラットフォームができました。オンプレミスにあったデータ収集機能はAWSへ移行しました。それらのサービスはマイクロサービス化し、それぞれのリージョンに配置しました。そして、Kafkaを使ってリージョン毎にデータ加工する仕組みを用意しました。

リージョン毎に加工されたデータは中央のサーバに送られ分析するという仕組みとなっています。

この分析プラットフォームによって以下のように問題を解決しました。

SchemaをJSON形式に

データ形式はjson形式に変更されました。また、データの内容に問題がないかバリデーションも行われるようになりました。

データをKafkaに直接書き込む

解決方法としては、Kafkaに直接書き込むようにしました。また、データのフローもSparkを通してDelta lakeについて書き込むようになりました。先にあったS3に書き込むプロセスがなくなったため、データ送信や保存が不用となりコストの削減にもつながっていきました。

S3に書き込むことがなくなったため、先ほどのmany small filesの問題も解決しました。

Streamingによるデータ

収集したデータをストリーミングジョブとして書き込むようにできるので、より楽にデータが取り扱えるようになりました。

分析結果をユーザへ反映する

これらの分析はユーザへの価値を提供することに使われています。例えば、マッチメイキング、ゲームバランスの調整などに利用されています。

まとめ

このセッションの中では、RIOT Gamesのなかでもさまざまな試行錯誤があって、いまの分析プラットフォームができたという歴史があるのがわかりました。

また、分析した結果は、よりユーザがプレイしやすい状況になるよう活用されていることがわかりました。